Re: [Scons-dev] Roundup tracker demo instance...

[Florian Miedniak]

 please note that the hosted trial version expires by tomorrow. I'll proceed 
with migration in a local instance and will make a demo with real data  
available again soon. -florian


On 4. Oktober 2015 09:54:09 MESZ, Florian Miedniak <florian.miedn...@gmail.com> 
wrote:
>Dirk,  thanks for clarifying! I'll give it a try and adapt the importer
>for jira, so we have an equal base for comparison with roundup.
>-florian 
>
> Original message 
>Subject: Re: [Scons-dev] Roundup tracker demo instance... 
>From: Dirk Baechle <tshor...@gmx.de> 
>To: SCons developer list <scons-dev@scons.org> 
>CC:  
>
>Hi Florian, 
>
>your mail sums it up pretty well. Thanks for taking the time to skim
>through those old messages. We definitely are interested in making
>progress wherever that's possible.
>But with a large project like SCons and major decisions to be made,
>"bikeshedding" is always around...and can bring things to a halt
>quickly. 
>Further, we did have a tracker and most of the latest development was
>done by direct pull requests...which might have let this problem appear
>as one of lower priority.
>I agree that it's time for a clear decision...from my angle the two
>candidates are Roundup and Jira. Both seem to be able to do the job on
>the technical level. So we can't choose "wrong" and just have to pick.
>Leaves the question how to do that. Would any of the devs be opposed to
>a simple poll, where everybody supports his favourite tool?
>
>Independent of how the decision is made, what will happen later is
>that-just like in the git vs hg battle-voices speak up from time to
>time, claiming that a switch to the other alternative is what the
>project needs right now. That's just how open-source works these days I
>guess. :)
>
>Best regards, 
>
>Dirk
>
>P.S.: I wrote all of the above under the assumption that the technical
>migration from Tigris to Jira is possible and preserves the full
>history, including the creation dates of issues and messages /comments.
>I'm stressing this point so much, because even in Roundup it's only
>possible with a work-around. ;)
>-- 
>Sent from my Android with K-9 Mail.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Roundup tracker demo instance...

[Florian Miedniak]

Dirk,  thanks for clarifying! I'll give it a try and adapt the importer for 
jira, so we have an equal base for comparison with roundup. -florian 

 Original message 
Subject: Re: [Scons-dev] Roundup tracker demo instance... 
From: Dirk Baechle  
To: SCons developer list  
CC:  

Hi Florian, 

your mail sums it up pretty well. Thanks for taking the time to skim through 
those old messages. We definitely are interested in making progress wherever 
that's possible.
But with a large project like SCons and major decisions to be made, 
"bikeshedding" is always around...and can bring things to a halt quickly. 
Further, we did have a tracker and most of the latest development was done by 
direct pull requests...which might have let this problem appear as one of lower 
priority.
I agree that it's time for a clear decision...from my angle the two candidates 
are Roundup and Jira. Both seem to be able to do the job on the technical 
level. So we can't choose "wrong" and just have to pick. Leaves the question 
how to do that. Would any of the devs be opposed to a simple poll, where 
everybody supports his favourite tool?

Independent of how the decision is made, what will happen later is that-just 
like in the git vs hg battle-voices speak up from time to time, claiming that a 
switch to the other alternative is what the project needs right now. That's 
just how open-source works these days I guess. :)

Best regards, 

Dirk

P.S.: I wrote all of the above under the assumption that the technical 
migration from Tigris to Jira is possible and preserves the full history, 
including the creation dates of issues and messages /comments. I'm stressing 
this point so much, because even in Roundup it's only possible with a 
work-around. ;)
-- 
Sent from my Android with K-9 Mail.___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Roundup tracker demo instance...

[Florian Miedniak]

Hope you find your way through that bunch of typos :-/

2015-10-03 0:06 GMT+02:00 Florian Miedniak <florian.miedn...@gmail.com>:

> Having spent some time to read the past scons-dev threads related to bug
> tracker. Let me summarize in short:
> - Tigris is badhttps://
> mail.google.com/mail/u/0/#label/scons%2Fscons-dev/150007f69c46a119v
> (considered awful)
> - Want another tracker, that is most attractive to contributors (make it
> easy to report bugs / feature requests)
> - New tracker shall integrate well with version control system (today:
> mercurial), hosting system (today: bitbucket). Integration with build
> system (today: buildbot) nice to have
> - New tracker preferably shall have no vendor-lockin regarding
> export/import and customizing the tracker itself
> - RoundUp was discussed as the future tracker
> - Discussion stalled about a year ago, when some problems occured on
> migration to RoundUp (import issues and some work left to get RoundUp in a
> "beautiful" state)
> - Import problems seem to be fixed (?) with latest demo by dirk, but
> reading recent comments of this thread, it seems that the demo doesn't
> provide a good enough user experience
> - Some prefer a hosted solution with less effort to maintain, even if that
> means a possible vendor-lockin
> - Others (totally) object to this and want to improve RoundUp instead (due
> to common roots with scons in software carpentry contest, written in
> python, open source)
>
> As far as I can see, there is little about the requirements for an issue
> tracker for scons that has not been said until know. ;-) What's left to do
> is "simply" to make a decision, which way to go:
> - Proceed with RoundUp / another open source issue tracker and host it
> ourselves
> - Watch out for and evaluate another issue tracker (that's possibly hosted)
>
> I heavily agree with Andrew Featherstone that a good issue tracker and the
> sane state of issue within it is *the *metric many people have a look on
> very early when evaluating an open source project. So honestly I'm a bit
> confused, that this topic seems to be neglected a bit (Reading through the
> threads felt like there is more discussion than action ...)  and IMO this
> just doesn't fit to the otherwise very smooth handling of contribution to
> the project, which I experienced recently :-)
>
> -Florian
>
> 2015-10-02 14:24 GMT+02:00 Dirk Baechle <tshor...@gmx.de>:
>
>> To everybody interested in this "bugtracker migration " thread,
>>
>> please read up on the scons-dev list threads "Is Tigris issue tracking
>> actively used " and "Bugtracker and stuff...", in order to better
>> understand what our main concerns with Tigris have been in the past and
>> where the decision to try Roundup comes from.
>> Thank you! :)
>>
>> Dirk
>>
>>
>> Am 2. Oktober 2015 13:47:33 MESZ, schrieb William Blevins <
>> wblevins...@gmail.com>:
>>>
>>> Same boat.  I just want our solution to work well and not require lots
>>> of overhead.  Any solution that meets this reasonably basic criteria is
>>> fine.
>>>
>>> On Fri, Oct 2, 2015 at 12:20 PM, Florian Miedniak <
>>> florian.miedn...@gmail.com> wrote:
>>>
>>>> Anatoly,
>>>>
>>>> be sure, I don't want to "sell" JIRA as the ultimate bug tracking tool
>>>> for developing scons ;-) From my experience, especially customizing its
>>>> configuration can imply effort, that's not small. I saw JIRA installations,
>>>> that both from a user's and admin's point of view are a pain because due to
>>>> heavy over-configuration.
>>>> The main reason for that I recommended it was, that for the existing
>>>> bitbucket environment it has good integration, that (and that's the point!)
>>>> works out-of-the-box.
>>>>
>>>> From my point of view the effort spent by a team for the services like
>>>> hosting, bugtracker, wiki, build server, ... should be always as small as
>>>> possible to allow for concentrating on the main task: Developing.
>>>>
>>>> In find it honorable, if there is a agreement in an open source project
>>>> like scons is one, to prefer the use of products that are itself open
>>>> source / written in python / ..., but I sometimes find it kind of
>>>> fundamelist ... A very common reason for not using open source projects
>>>> like scons is, that people even if they consider the product itself
>>>> outstanding, they don't trust the community to be strong enough to maintain

Re: [Scons-dev] Roundup tracker demo instance...

[Florian Miedniak]

Having spent some time to read the past scons-dev threads related to bug
tracker. Let me summarize in short:
- Tigris is badhttps://
mail.google.com/mail/u/0/#label/scons%2Fscons-dev/150007f69c46a119v
(considered awful)
- Want another tracker, that is most attractive to contributors (make it
easy to report bugs / feature requests)
- New tracker shall integrate well with version control system (today:
mercurial), hosting system (today: bitbucket). Integration with build
system (today: buildbot) nice to have
- New tracker preferably shall have no vendor-lockin regarding
export/import and customizing the tracker itself
- RoundUp was discussed as the future tracker
- Discussion stalled about a year ago, when some problems occured on
migration to RoundUp (import issues and some work left to get RoundUp in a
"beautiful" state)
- Import problems seem to be fixed (?) with latest demo by dirk, but
reading recent comments of this thread, it seems that the demo doesn't
provide a good enough user experience
- Some prefer a hosted solution with less effort to maintain, even if that
means a possible vendor-lockin
- Others (totally) object to this and want to improve RoundUp instead (due
to common roots with scons in software carpentry contest, written in
python, open source)

As far as I can see, there is little about the requirements for an issue
tracker for scons that has not been said until know. ;-) What's left to do
is "simply" to make a decision, which way to go:
- Proceed with RoundUp / another open source issue tracker and host it
ourselves
- Watch out for and evaluate another issue tracker (that's possibly hosted)

I heavily agree with Andrew Featherstone that a good issue tracker and the
sane state of issue within it is *the *metric many people have a look on
very early when evaluating an open source project. So honestly I'm a bit
confused, that this topic seems to be neglected a bit (Reading through the
threads felt like there is more discussion than action ...)  and IMO this
just doesn't fit to the otherwise very smooth handling of contribution to
the project, which I experienced recently :-)

-Florian

2015-10-02 14:24 GMT+02:00 Dirk Baechle <tshor...@gmx.de>:

> To everybody interested in this "bugtracker migration " thread,
>
> please read up on the scons-dev list threads "Is Tigris issue tracking
> actively used " and "Bugtracker and stuff...", in order to better
> understand what our main concerns with Tigris have been in the past and
> where the decision to try Roundup comes from.
> Thank you! :)
>
> Dirk
>
>
> Am 2. Oktober 2015 13:47:33 MESZ, schrieb William Blevins <
> wblevins...@gmail.com>:
>>
>> Same boat.  I just want our solution to work well and not require lots of
>> overhead.  Any solution that meets this reasonably basic criteria is fine.
>>
>> On Fri, Oct 2, 2015 at 12:20 PM, Florian Miedniak <
>> florian.miedn...@gmail.com> wrote:
>>
>>> Anatoly,
>>>
>>> be sure, I don't want to "sell" JIRA as the ultimate bug tracking tool
>>> for developing scons ;-) From my experience, especially customizing its
>>> configuration can imply effort, that's not small. I saw JIRA installations,
>>> that both from a user's and admin's point of view are a pain because due to
>>> heavy over-configuration.
>>> The main reason for that I recommended it was, that for the existing
>>> bitbucket environment it has good integration, that (and that's the point!)
>>> works out-of-the-box.
>>>
>>> From my point of view the effort spent by a team for the services like
>>> hosting, bugtracker, wiki, build server, ... should be always as small as
>>> possible to allow for concentrating on the main task: Developing.
>>>
>>> In find it honorable, if there is a agreement in an open source project
>>> like scons is one, to prefer the use of products that are itself open
>>> source / written in python / ..., but I sometimes find it kind of
>>> fundamelist ... A very common reason for not using open source projects
>>> like scons is, that people even if they consider the product itself
>>> outstanding, they don't trust the community to be strong enough to maintain
>>> and support the project properly because the members have lots of tasks to
>>> do that are not directly related to the product.
>>> I don't know the scons project good enough yet, to know if there is a
>>> rather idealistic or more pragmatic view on this topic.
>>> I'm able to speak for myself only: I'm rather a pragmatist. If RoundUp
>>> or any other tool(set) can provide a similar degree of integration wi

Re: [Scons-dev] Roundup tracker demo instance...

[Florian Miedniak]

Not exactly ... I simply forgot to add Gary's email address as user :-/
@Gary: You now should have received an email with your username and a link
to set the password.

2015-10-01 10:37 GMT+02:00 William Blevins <wblevins...@gmail.com>:

>
>
> On Thu, Oct 1, 2015 at 3:14 AM, Gary Oberbrunner <ga...@oberbrunner.com>
> wrote:
>
>> I don't seem to have any access.  "Forgot password" doesn't work with any
>> username I tried...
>>
>
> You have to use an email address.  It sets up a fake account (I think).
> You forgot username.
>
>>
>> On Wed, Sep 30, 2015 at 4:58 PM, Florian Miedniak <
>> florian.miedn...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have created a on-demand trial setup of the JIRA + bitbucket
>>> integration here: https://scsandbox.atlassian.net with write access to
>>> both parts for Dirk, Gary, Bill Deegan and William Blevins. I'm sure
>>> there's someone I forgot ;-) Just tell me and I'll add you to the users
>>> list.
>>> The very basic integration works:
>>>   - Mention a JIRA issue (SCSAND-) in a commit message and push
>>> it to https://bitbucket.org/scsandbox/jira_bitbucket_integration -> The
>>> issue name will be a hyper-linked to JIRA
>>>  - If you open a JIRA issue on the right there is a section
>>> "Development" which shows all commits belonging to this issue. Here you can
>>> step-wise dive into the commit until you end up on bitbucket's commit view
>>> - It is possible (but not yet configured) to modify the standard JIRA
>>> issue workflow, so an issue e.g. transits to REVIEW to FIXED when a pull
>>> request gets merged. (And there is a ton of other event/notification
>>> configuration options available ...)
>>>
>>> The trial setup is available until 2015/10/6 (due to the trial license),
>>> so feel free to check its look and feel!
>>>
>>> -Florian
>>>
>>> 2015-09-29 8:52 GMT+02:00 Florian Miedniak <florian.miedn...@gmail.com>:
>>>
>>>>
>>>>
>>>> 2015-09-28 21:42 GMT+02:00 William Blevins <wblevins...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 28, 2015 at 7:45 PM, Russel Winder <rus...@winder.org.uk>
>>>>> wrote:
>>>>>
>>>>>> On Mon, 2015-09-28 at 13:56 +0100, William L Blevins wrote:
>>>>>> > […]
>>>>>> > I have used Jira and I think if we can get free instances for the
>>>>>> > project, then the direct jira -> bitbucket <- confluence setup will
>>>>>> > give us a lot of project management control.
>>>>>>
>>>>>> Personally I found Confluence a right royal pain in the arse. JIRA on
>>>>>> the other hand worked very well for me. The issue is whether SCons can
>>>>>> have a JIRA directly linked to the Mercurial repository and its pull
>>>>>> requests.
>>>>>>
>>>>>
>>>>>
>>>>> Since they are all Atlassian products, I cannot imagine "no" to be the
>>>>> answer; otherwise, what is the point?
>>>>>
>>>>>
>>>> William, I agree with you, that it is not the question, *if* there is
>>>> support for connecting bitbucket hosted mercurial repos with JIRA. (
>>>> http://blogs.atlassian.com/2012/07/connect-jira-to-your-git-or-mercurial-repositories-with-the-jira-dvcs-connector)
>>>> It's more the question how mature it is. From my previous experience,
>>>> Atlassian does a quite good job of integrating their products.
>>>> Nevertheless, the best (and IMO only) way to find out, if there are any
>>>> technical / user experiance obstacles left for using JIRA<->Bitbucket for
>>>> Scons, is to give it a try:
>>>> 1. Check for JIRA<->Mercurial on Bitbucket integration with a sandbox
>>>> project
>>>> 2. Adapt the scripts of Dirk to import the existing issues from tigris
>>>>
>>>> I'd volunteer to do this to have a solid basis for further
>>>> decision-making.
>>>>
>>>> -Florian
>>>>
>>>
>>>
>>> ___
>>> Scons-dev mailing list
>>> Scons-dev@scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>>>
>>
>>
>> --
>> Gary
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Roundup tracker demo instance...

[Florian Miedniak]

I left out the JIRA agile option in the first run to make it less
complicated to setup and overview, but it's a good idea to check this, too.
Import of attachements seems to be possible even with CSV importer. Maybe
with other "generic" importers (JSON) as well. I deferred this, although
it's criticial, to the second step of evaluation just in case the majority
dislikes JIRA ... ;-)

2015-09-30 23:47 GMT+02:00 William Blevins <wblevins...@gmail.com>:

> Any chance we could also demo with the agile plugins?  I would like to
> have the kanban board in the demo to show easy workflow patterns.
>
> On Wed, Sep 30, 2015 at 10:43 PM, William Blevins <wblevins...@gmail.com>
> wrote:
>
>> I think it's reasonable as long as we can convert everything over.  Looks
>> like issues can be imported from csv, but I don't know what happens with
>> attachments.  Would need to lookup the format requirements.
>>
>> On Wed, Sep 30, 2015 at 10:38 PM, William Blevins <wblevins...@gmail.com>
>> wrote:
>>
>>> What type of layout is this?  Kanban?
>>>
>>> On Wed, Sep 30, 2015 at 10:34 PM, William Blevins <wblevins...@gmail.com
>>> > wrote:
>>>
>>>> The answer to my question is that it has to be created through password
>>>> recovery using your email.  I guess the account isn't related.
>>>>
>>>> On Wed, Sep 30, 2015 at 10:27 PM, William Blevins <
>>>> wblevins...@gmail.com> wrote:
>>>>
>>>>> I don't seem to be able to login with my bitbucket account.  Is an
>>>>> Atlassian Cloud account different?
>>>>>
>>>>> On Wed, Sep 30, 2015 at 9:58 PM, Florian Miedniak <
>>>>> florian.miedn...@gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have created a on-demand trial setup of the JIRA + bitbucket
>>>>>> integration here: https://scsandbox.atlassian.net with write access
>>>>>> to both parts for Dirk, Gary, Bill Deegan and William Blevins. I'm sure
>>>>>> there's someone I forgot ;-) Just tell me and I'll add you to the users
>>>>>> list.
>>>>>> The very basic integration works:
>>>>>>   - Mention a JIRA issue (SCSAND-) in a commit message and
>>>>>> push it to https://bitbucket.org/scsandbox/jira_bitbucket_integration
>>>>>> -> The issue name will be a hyper-linked to JIRA
>>>>>>  - If you open a JIRA issue on the right there is a section
>>>>>> "Development" which shows all commits belonging to this issue. Here you 
>>>>>> can
>>>>>> step-wise dive into the commit until you end up on bitbucket's commit 
>>>>>> view
>>>>>> - It is possible (but not yet configured) to modify the standard JIRA
>>>>>> issue workflow, so an issue e.g. transits to REVIEW to FIXED when a pull
>>>>>> request gets merged. (And there is a ton of other event/notification
>>>>>> configuration options available ...)
>>>>>>
>>>>>> The trial setup is available until 2015/10/6 (due to the trial
>>>>>> license), so feel free to check its look and feel!
>>>>>>
>>>>>> -Florian
>>>>>>
>>>>>> 2015-09-29 8:52 GMT+02:00 Florian Miedniak <
>>>>>> florian.miedn...@gmail.com>:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2015-09-28 21:42 GMT+02:00 William Blevins <wblevins...@gmail.com>:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Sep 28, 2015 at 7:45 PM, Russel Winder <
>>>>>>>> rus...@winder.org.uk> wrote:
>>>>>>>>
>>>>>>>>> On Mon, 2015-09-28 at 13:56 +0100, William L Blevins wrote:
>>>>>>>>> > […]
>>>>>>>>> > I have used Jira and I think if we can get free instances for the
>>>>>>>>> > project, then the direct jira -> bitbucket <- confluence setup
>>>>>>>>> will
>>>>>>>>> > give us a lot of project management control.
>>>>>>>>>
>>>>>>>>> Personally I found Confluence a right royal pain in the arse. JIRA
>>>>>&g

Re: [Scons-dev] Roundup tracker demo instance...

[Florian Miedniak]

Yes, it seems so. I'm not totally sure, if that is because of the cloud
thing or because they don't accept bitbucket accounts for their other
services at all ...

2015-09-30 23:34 GMT+02:00 William Blevins <wblevins...@gmail.com>:

> The answer to my question is that it has to be created through password
> recovery using your email.  I guess the account isn't related.
>
> On Wed, Sep 30, 2015 at 10:27 PM, William Blevins <wblevins...@gmail.com>
> wrote:
>
>> I don't seem to be able to login with my bitbucket account.  Is an
>> Atlassian Cloud account different?
>>
>> On Wed, Sep 30, 2015 at 9:58 PM, Florian Miedniak <
>> florian.miedn...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have created a on-demand trial setup of the JIRA + bitbucket
>>> integration here: https://scsandbox.atlassian.net with write access to
>>> both parts for Dirk, Gary, Bill Deegan and William Blevins. I'm sure
>>> there's someone I forgot ;-) Just tell me and I'll add you to the users
>>> list.
>>> The very basic integration works:
>>>   - Mention a JIRA issue (SCSAND-) in a commit message and push
>>> it to https://bitbucket.org/scsandbox/jira_bitbucket_integration -> The
>>> issue name will be a hyper-linked to JIRA
>>>  - If you open a JIRA issue on the right there is a section
>>> "Development" which shows all commits belonging to this issue. Here you can
>>> step-wise dive into the commit until you end up on bitbucket's commit view
>>> - It is possible (but not yet configured) to modify the standard JIRA
>>> issue workflow, so an issue e.g. transits to REVIEW to FIXED when a pull
>>> request gets merged. (And there is a ton of other event/notification
>>> configuration options available ...)
>>>
>>> The trial setup is available until 2015/10/6 (due to the trial license),
>>> so feel free to check its look and feel!
>>>
>>> -Florian
>>>
>>> 2015-09-29 8:52 GMT+02:00 Florian Miedniak <florian.miedn...@gmail.com>:
>>>
>>>>
>>>>
>>>> 2015-09-28 21:42 GMT+02:00 William Blevins <wblevins...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 28, 2015 at 7:45 PM, Russel Winder <rus...@winder.org.uk>
>>>>> wrote:
>>>>>
>>>>>> On Mon, 2015-09-28 at 13:56 +0100, William L Blevins wrote:
>>>>>> > […]
>>>>>> > I have used Jira and I think if we can get free instances for the
>>>>>> > project, then the direct jira -> bitbucket <- confluence setup will
>>>>>> > give us a lot of project management control.
>>>>>>
>>>>>> Personally I found Confluence a right royal pain in the arse. JIRA on
>>>>>> the other hand worked very well for me. The issue is whether SCons can
>>>>>> have a JIRA directly linked to the Mercurial repository and its pull
>>>>>> requests.
>>>>>>
>>>>>
>>>>>
>>>>> Since they are all Atlassian products, I cannot imagine "no" to be the
>>>>> answer; otherwise, what is the point?
>>>>>
>>>>>
>>>> William, I agree with you, that it is not the question, *if* there is
>>>> support for connecting bitbucket hosted mercurial repos with JIRA. (
>>>> http://blogs.atlassian.com/2012/07/connect-jira-to-your-git-or-mercurial-repositories-with-the-jira-dvcs-connector)
>>>> It's more the question how mature it is. From my previous experience,
>>>> Atlassian does a quite good job of integrating their products.
>>>> Nevertheless, the best (and IMO only) way to find out, if there are any
>>>> technical / user experiance obstacles left for using JIRA<->Bitbucket for
>>>> Scons, is to give it a try:
>>>> 1. Check for JIRA<->Mercurial on Bitbucket integration with a sandbox
>>>> project
>>>> 2. Adapt the scripts of Dirk to import the existing issues from tigris
>>>>
>>>> I'd volunteer to do this to have a solid basis for further
>>>> decision-making.
>>>>
>>>> -Florian
>>>>
>>>
>>>
>>> ___
>>> Scons-dev mailing list
>>> Scons-dev@scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>>>
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Roundup tracker demo instance...

[Florian Miedniak]

2015-09-28 21:42 GMT+02:00 William Blevins :

>
>
> On Mon, Sep 28, 2015 at 7:45 PM, Russel Winder 
> wrote:
>
>> On Mon, 2015-09-28 at 13:56 +0100, William L Blevins wrote:
>> > […]
>> > I have used Jira and I think if we can get free instances for the
>> > project, then the direct jira -> bitbucket <- confluence setup will
>> > give us a lot of project management control.
>>
>> Personally I found Confluence a right royal pain in the arse. JIRA on
>> the other hand worked very well for me. The issue is whether SCons can
>> have a JIRA directly linked to the Mercurial repository and its pull
>> requests.
>>
>
>
> Since they are all Atlassian products, I cannot imagine "no" to be the
> answer; otherwise, what is the point?
>
>
William, I agree with you, that it is not the question, *if* there is
support for connecting bitbucket hosted mercurial repos with JIRA. (
http://blogs.atlassian.com/2012/07/connect-jira-to-your-git-or-mercurial-repositories-with-the-jira-dvcs-connector)
It's more the question how mature it is. From my previous experience,
Atlassian does a quite good job of integrating their products.
Nevertheless, the best (and IMO only) way to find out, if there are any
technical / user experiance obstacles left for using JIRA<->Bitbucket for
Scons, is to give it a try:
1. Check for JIRA<->Mercurial on Bitbucket integration with a sandbox
project
2. Adapt the scripts of Dirk to import the existing issues from tigris

I'd volunteer to do this to have a solid basis for further decision-making.

-Florian
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Roundup tracker demo instance...

[Florian Miedniak]

Thought about using JIRA? It's free for open source projects and very
intuitive to use IMO while being very flexible, if you need it. Nice
integration with bitbucket, confluence and version control system is also
given (automated cross-references for issues, detailed track of commits per
issue).

-Florian

2015-09-25 1:33 GMT+02:00 William Blevins :

> I don't mind either way; I was just curious.
>
> On Fri, Sep 25, 2015 at 12:24 AM, Gary Oberbrunner 
> wrote:
>
>>
>> On Thu, Sep 24, 2015 at 2:17 PM, William Blevins 
>> wrote:
>>
>>> Functionality wise, what does round-up provide that tigris doesn't?
>>
>>
>> Lack of awfulness.  IMHO of course. :-)
>>
>> That's the most objective description yet.  I'm convenced 100% now :)
>
>
>> --
>> Gary
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Roundup tracker demo instance...

[Florian Miedniak]

Dirk, a copy of the script would be nice, so I could have a very first try,
if a migration would be possible in general.

-Florian

2015-09-25 10:47 GMT+02:00 Dirk Baechle <tshor...@gmx.de>:

> Florian,
>
> thanks for the additional info about Jira license fees.
> My converter script pulls the issues from Tigris to a folder in XML
> format. From there, they get pushed into Roundup via its RPC interface. So
> you'd have to care only about the second part only.
> If you're interested, I can send you a copy of the script.
>
> Best regards,
>
> Dirk
>
>
> Am 25. September 2015 09:58:22 MESZ, schrieb Florian Miedniak <
> florian.miedn...@gmail.com>:
>>
>> Hi Dirk,
>>
>> here are the detailed conditions for their open source program:
>> https://www.atlassian.com/software/views/open-source-license-request
>>
>> I didn't see a restriction to cloud instances on the first glance -
>> although this kind of restrictions usually are stated in very small print
>> ;-)
>>
>>
>> 2015-09-25 9:12 GMT+02:00 Dirk Bächle <tshor...@gmx.de>:
>>
>>> Hi Florian,
>>>
>>> On 25.09.2015 08:54, Florian Miedniak wrote:
>>>
>>>> Thought about using JIRA? It's free for open source projects
>>>>
>>>
>>> I'm not sure that this is a 100% correct. From their main website I get
>>> the information that the "Cloud service" can be free for open-source
>>> project that apply for this. Can you point me to the information where it
>>> says that Jira itself is free too?
>>> I'm asking because I know that my company plans to use Jira pretty
>>> big-scale in the future, which means there must be some serious money
>>> involved...else they wouldn't buy it. ;)
>>>
>>
>> We're using JIRA in commercial environment, which for sure costs "some"
>> money, especially if you use their standard per-user licenses.
>>
>>
>>> and very intuitive to use IMO while being very flexible, if you need
>>>
>>>> it. Nice integration with bitbucket, confluence and version control
>>>> system is also given (automated cross-references for issues,
>>>> detailed track of commits per issue).
>>>>
>>>
>>> The main point here is the migration from our Tigris instance. If you
>>> (or someone else) can come up with a way to import all the currently
>>> existing data into Jira, without losing any attached files or creation
>>> dates of messages and issues (preserving history), then we can talk I
>>> guess. :)
>>>
>>
>> That really could be the crucial point - as migration is often ... :-/ I
>> may talk to the colleague, that did the migration into JIRA, maybe he has
>> some valueable hints.
>> How are you doing this for Tigris -> Roundup currently? Especially the
>> attachement thing? Do you have some kind of intermediate format for
>> migration?
>>
>> I had a look on the feature sheet of Roundup, that admittedly reads quite
>> impressive. Nevertheless, I must agree with Gary concerning the user
>> interface ... For me, at first glance it compares it bit to Trac from the
>> "user experience" point of view.
>>
>> Best regards
>>
>> -Florian
>> ___
>>
>>> Scons-dev mailing list
>>> Scons-dev@scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>>
>>
> --
> Sent from my Android with K-9 Mail.
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Fw: Re: [Scons-users] Glob() exclude doesn't match when used inside VariantDir

[Florian Miedniak]

Great to see the fix being merged upstream within a week! One question
left: Shall I leave the tigris issue in state RESOLVED:FIXED with target
milestone UNSPECIFIED? Or shall I set target milestone to 2.x (and leaving
it open)? What is the recommended way to ensure that solved tickets like
this get closed on (next) release?

-Florian

2015-09-24 8:47 GMT+02:00 Florian Miedniak <florian.miedn...@web.de>:

>
>
> *Gesendet:* Dienstag, 22. September 2015 um 12:43 Uhr
> *Von:* "Florian Miedniak" <florian.miedn...@web.de>
> *An:* scons-dev@scons.org
> *Betreff:* [Scons-dev] Fw: Re: [Scons-users] Glob() exclude doesn't match
> when used inside VariantDir
> Posted, just to preserve the thread history from scons-user list.
>
> *Gesendet:* Dienstag, 22. September 2015 um 12:00 Uhr
> *Von:* "William L Blevins" <wblevins...@gmail.com>
> *An:* "SCons users mailing list" <scons-us...@scons.org>
> *Betreff:* Re: [Scons-users] Glob() exclude doesn't match when used
> inside VariantDir
>
> I would argue it's more for the developer list now.
>
> V/R,
> William
>
>
> On September 22, 2015, at 10:39 AM, Florian Miedniak <
> florian.miedn...@web.de> wrote:
>
>
> Hi Bill,
>
> I just created a pull request for the issue:
> https://bitbucket.org/scons/scons/pull-requests/252/fixed-3011-glob-called-with-exclude-didnt/diff
>
> Notes:
> - Is it okay to discuss this further on scons-user?
> - [offtopic] I just did a python bootstrap.py and was overwhelmed how
> simply it is to "build" SCons! The people maintaining our development
> environment just couldn't believe getting a rpm with a local scons build
> including my changes for deployment ...
>
> -Florian
>
> *Gesendet:* Donnerstag, 17. September 2015 um 15:24 Uhr
> *Von:* "Bill Deegan" <b...@baddogconsulting.com>
> *An:* "SCons users mailing list" <scons-us...@scons.org>
> *Betreff:* Re: [Scons-users] Glob() exclude doesn't match when used
> inside VariantDir
> Thanks!
> -Bill
>
> On Thu, Sep 17, 2015 at 3:40 AM, Florian Miedniak <florian.miedn...@web.de
> > wrote:
>>
>> Hi Bill,
>>
>> I just created an issue in bug tracker (#3011) and will provide a pull
>> request as you suggested for further discussion.
>>
>> -Florian
>>
>> *Gesendet:* Mittwoch, 16. September 2015 um 16:46 Uhr
>> *Von:* "Bill Deegan" <b...@baddogconsulting.com>
>> *An:* "SCons users mailing list" <scons-us...@scons.org>
>> *Betreff:* Re: [Scons-users] Glob() exclude doesn't match when used
>> inside VariantDir
>> Florian,
>>
>> Good catch on the bug still being open. I've closed it. (It should have
>> been as the feature is (in theory) complete)
>>
>> The preferred method for sending a patch would be to fork the scons repo
>> and send a pull request.
>> Any chance we can ask you to do that?
>> That way the version history would properly represent who made the fix.
>>
>> -Bill
>>
>>
>> On Wed, Sep 16, 2015 at 7:35 AM, Florian Miedniak <
>> florian.miedn...@web.de> wrote:
>>>
>>> Hi,
>>>
>>> first of all, I'm very glad scons now has support for exclude patterns
>>> for Glob()! Compared to the prior workarounds the solution IMO fits
>>> perfectly in the scons way of declaring artifacts.
>>>
>>> Nevertheless, I think I've found a bug or at least a from my point of
>>> view unexpected behaviour when using Glob-excludes together with variant
>>> dirs: When Glob is called within a separate SConscript, it fails to
>>> properly apply exclude patterns because the returned list of files contains
>>> path information (see attached testcase for details).
>>>
>>> I think I found the place in FS.py (SCons 2.3.6) where things go wrong.
>>> With attached patch, the problem went away for me. But I'm not yet sure, if
>>> I really found the root cause or just a workaround. In addition to that,
>>> I'm very uncertain about possible side-effects of the patch ...
>>> So I'd very like someone to review both the testcase and, if it is
>>> considered valid, the proposed patch.
>>>
>>> An additional note: While tracking down the problem, I found these issue
>>> 2545 in state NEW whereas Git commits fc2659e and 81e0a43 seem
>>> to fix this issue. Does the issue still being in state NEW mean, that
>>> implementation of the exclude feature is considered still incomplete?
>>>
>>>
>>> Regards,
>>> -Florian
>>>
>>> _