Version trunk in bugzilla

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Version trunk in bugzilla

Mechtilde Stehmann-2
Hello,

can we get the version "trunk2 in bugzilla to track the issues which
comms there and are not in the 420-dev branch.

Kind regards

--
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Version trunk in bugzilla

Peter Kovacs-3
Maybe a version trunk would help?

On 19.01.19 08:13, Mechtilde wrote:
> Hello,
>
> can we get the version "trunk2 in bugzilla to track the issues which
> comms there and are not in the 420-dev branch.
>
> Kind regards
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Version trunk in bugzilla

Marcus (OOo)
Am 19.01.19 um 09:39 schrieb Peter Kovacs:
> Maybe a version trunk would help?

before I spent 30 minutes to update all the products in BZ with a new
version let me summarize what we have and what is really needed:





- trunk is used to commit changes that could be integrated in a release
somewhen in the future - so, totally unspecified in time. IMHO it's not
helpful as it is not clear at which point in time it was trunk and when
no longer. In SVN, etc. it's OK but not in an issue tracker.

- trunk2 (I don't know if this was just a typo) doesn't tell me what
could be meant.

- 4.5.0 is possible - but what's about 4.3.0 and 4.4.0 - do we want to
skip them? At the moment I cannot imagine for what reason.

The suggestion is to plan with a 4.3.0 when 4.2.0 is done and released.
Sure, maybe there is a big change that would justify a 5.0.0 release.
But at the moment nobody can oversee this.

My proposal is to create a 4.3.0 version (or better milestone) to use
for every commit to trunk. The consequence is that the code in trunk has
to be adjusted (again) to replace every line that include a 4.5.0 with
4.3.0.

What do you all think?

Thanks

Marcus



> On 19.01.19 08:13, Mechtilde wrote:
>> can we get the version "trunk2 in bugzilla to track the issues which
>> comms there and are not in the 420-dev branch.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Version trunk in bugzilla

Mechtilde Stehmann-2
Hello,


Am 19.01.19 um 12:11 schrieb Marcus:
> Am 19.01.19 um 09:39 schrieb Peter Kovacs:
>> Maybe a version trunk would help?
>
> before I spent 30 minutes to update all the products in BZ with a new
> version let me summarize what we have and what is really needed:
>

> - trunk is used to commit changes that could be integrated in a release
> somewhen in the future - so, totally unspecified in time. IMHO it's not
> helpful as it is not clear at which point in time it was trunk and when
> no longer. In SVN, etc. it's OK but not in an issue tracker.
>
> - trunk2 (I don't know if this was just a typo) doesn't tell me what
> could be meant.

This is a typo and should be "trunk"

>
> - 4.5.0 is possible - but what's about 4.3.0 and 4.4.0 - do we want to
> skip them? At the moment I cannot imagine for what reason.
>
> The suggestion is to plan with a 4.3.0 when 4.2.0 is done and released.
> Sure, maybe there is a big change that would justify a 5.0.0 release.
> But at the moment nobody can oversee this.
>
> My proposal is to create a 4.3.0 version (or better milestone) to use
> for every commit to trunk. The consequence is that the code in trunk has
> to be adjusted (again) to replace every line that include a 4.5.0 with
> 4.3.0.
>
> What do you all think?
or is it better to submit the bugreport (at this time to (4.2.0) as I
did it with #128012?

>
> Thanks
>
> Marcus
>
Thanks

--
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Version trunk in bugzilla

Marcus (OOo)
Am 19.01.19 um 12:24 schrieb Mechtilde:

> Hello,
>
>
> Am 19.01.19 um 12:11 schrieb Marcus:
>> Am 19.01.19 um 09:39 schrieb Peter Kovacs:
>>> Maybe a version trunk would help?
>>
>> before I spent 30 minutes to update all the products in BZ with a new
>> version let me summarize what we have and what is really needed:
>>
>
>> - trunk is used to commit changes that could be integrated in a release
>> somewhen in the future - so, totally unspecified in time. IMHO it's not
>> helpful as it is not clear at which point in time it was trunk and when
>> no longer. In SVN, etc. it's OK but not in an issue tracker.
>>
>> - trunk2 (I don't know if this was just a typo) doesn't tell me what
>> could be meant.
>
> This is a typo and should be "trunk"
>>
>> - 4.5.0 is possible - but what's about 4.3.0 and 4.4.0 - do we want to
>> skip them? At the moment I cannot imagine for what reason.
>>
>> The suggestion is to plan with a 4.3.0 when 4.2.0 is done and released.
>> Sure, maybe there is a big change that would justify a 5.0.0 release.
>> But at the moment nobody can oversee this.
>>
>> My proposal is to create a 4.3.0 version (or better milestone) to use
>> for every commit to trunk. The consequence is that the code in trunk has
>> to be adjusted (again) to replace every line that include a 4.5.0 with
>> 4.3.0.
>>
>> What do you all think?
>
> or is it better to submit the bugreport (at this time to (4.2.0) as I
> did it with #128012?

yes, you can do this. And as version you can use 4.2.0-dev. This would
be totally OK. However, the big question is: what it the target for this
issue and its fix when it wouldn't be 4.2.0? ;-)

Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Version trunk in bugzilla

Marcus (OOo)
In reply to this post by Marcus (OOo)
No further opinions? Come on :-)

Marcus



Am 19.01.19 um 12:11 schrieb Marcus:

> Am 19.01.19 um 09:39 schrieb Peter Kovacs:
>> Maybe a version trunk would help?
>
> before I spent 30 minutes to update all the products in BZ with a new
> version let me summarize what we have and what is really needed:
>
>
>
>
>
> - trunk is used to commit changes that could be integrated in a release
> somewhen in the future - so, totally unspecified in time. IMHO it's not
> helpful as it is not clear at which point in time it was trunk and when
> no longer. In SVN, etc. it's OK but not in an issue tracker.
>
> - trunk2 (I don't know if this was just a typo) doesn't tell me what
> could be meant.
>
> - 4.5.0 is possible - but what's about 4.3.0 and 4.4.0 - do we want to
> skip them? At the moment I cannot imagine for what reason.
>
> The suggestion is to plan with a 4.3.0 when 4.2.0 is done and released.
> Sure, maybe there is a big change that would justify a 5.0.0 release.
> But at the moment nobody can oversee this.
>
> My proposal is to create a 4.3.0 version (or better milestone) to use
> for every commit to trunk. The consequence is that the code in trunk has
> to be adjusted (again) to replace every line that include a 4.5.0 with
> 4.3.0.
>
> What do you all think?
>
> Thanks
>
> Marcus
>
>
>
>> On 19.01.19 08:13, Mechtilde wrote:
>>> can we get the version "trunk2 in bugzilla to track the issues which
>>> comms there and are not in the 420-dev branch.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Version trunk in bugzilla

Andrea Pescetti-2
Marcus write:
> No further opinions? Come on :-)

More or less, my opinion is the same as yours: we can't use "trunk"
since trunk is a moving target ("trunk" today is something different
than "trunk" in a few months). I think we used codes such as 4.2.0-dev
and this should be the way to go, so 4.3.0-dev would be a natural
choice. Of course, we might want to use different numbers in future, but
for the moment this is better than a generic "trunk".

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Version trunk in bugzilla

Jim Jagielski
works for me :)

> On Jan 24, 2019, at 4:26 PM, Andrea Pescetti <[hidden email]> wrote:
>
> Marcus write:
>> No further opinions? Come on :-)
>
> More or less, my opinion is the same as yours: we can't use "trunk" since trunk is a moving target ("trunk" today is something different than "trunk" in a few months). I think we used codes such as 4.2.0-dev and this should be the way to go, so 4.3.0-dev would be a natural choice. Of course, we might want to use different numbers in future, but for the moment this is better than a generic "trunk".
>
> Regards,
>  Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Version trunk in bugzilla

Marcus (OOo)
Sorry for being a bit late.

For all products that allow new issues I've created the follwoing:

Version   - "4.3.0-dev" to label issues where it was found.
Milestone - "4.3.0" to label where a fix should go into.

When something should be missing just give me a hint.

@All:
I just want to remind you that the version in code needs to be changed
from 4.5.0 to 4.3.0. Jim has done this so quickly and noiseless, maybe
he is willing to do the change again. ;-)

Thanks

Marcus



Am 24.01.19 um 22:35 schrieb Jim Jagielski:
> works for me :)
>
>> On Jan 24, 2019, at 4:26 PM, Andrea Pescetti <[hidden email]> wrote:
>>
>> Marcus write:
>>> No further opinions? Come on :-)
>>
>> More or less, my opinion is the same as yours: we can't use "trunk" since trunk is a moving target ("trunk" today is something different than "trunk" in a few months). I think we used codes such as 4.2.0-dev and this should be the way to go, so 4.3.0-dev would be a natural choice. Of course, we might want to use different numbers in future, but for the moment this is better than a generic "trunk".


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]